plex flight profile to be simulated, as 
well as ambient conditions and deterio- 
ration level of the engine. C-MAPSS40k 
has three actuators: fuel flow, variable 
stator vanes, and variable bleed valve. 
The three actuators enable off-nominal 
operation, which is not possible with 
simulations that have fuel flow as the 
sole actuator, since in those simulations 
the other actuators are implicit and as- 
sumed to operate nominally. The simu- 
lation is modular to allow users to re- 
design or replace components such as 
the engine controller or turbomachin- 
ery components without having to mod- 
ify the rest of the simulation. It also en- 
ables the user to view and save any signal 


in the engine or controller. The package 
has the capability to create and validate 
a linear model of the engine at any oper- 
ating point. Linear models can be used 
for control design, and C-MAPSS40k 
lends itself well to implementation and 
evaluation of advanced control designs 
as well as to diagnostic and prognostic 
system development. The simulation 
can be run in real time and can there- 
fore be integrated into a flight simulator 
with a pilot in the loop for testing. 

C-MAPSS40k fills the need for an easy- 
to-use, realistic, transient simulation of a 
medium-size commercial turbofan en- 
gine with a representative controller. It 
is a detailed component level model 


(CLM) written in the industry-standard 
graphical MATLAB/ Simulink environ- 
ment to allow for easy modification and 
portability. At the time of this reporting, 
no other such model exists in the public 
domain. 

This work was done by Ten-Huei Guo, 
Thomas Lavelle, and Jonathan Litt of Glenn 
Research Center and Jeffrey Csank of N&fR En- 
gineering and Ryan May of ASRC. Further in- 
formation is contained in a TSP (see page 1 ). 

Inquiries concerning rights for the commer- 
cial use of this invention should be addressed 
to NASA Glenn Research Center, Innovative 
Partnerships Office, Attn: Steven Fedor, Mail 
Stop 4-8, 21000 Brookpark Road, Cleve- 
land, Ohio 44135. Refer to LEW-18624-1. 


The Planning Execution Monitoring Architecture 

Lyndon B. Johnson Space Center, Houston, Texas 


The Planning Execution Monitoring 
(PEM) architecture is a design concept 
for developing autonomous cockpit 
command and control software. The 
PEM architecture is designed to reduce 
the operations costs in the space trans- 
portation system through the use of au- 
tomation while improving safety and op- 
erability of the system. Specifically, the 
PEM autonomous framework enables 
automatic performance of many vehicle 
operations that would typically be per- 
formed by a human. Also, this frame- 
work supports varying levels of au- 
tonomous control, ranging from fully 
automatic to fully manual control. 

The PEM autonomous framework in- 
terfaces with the “core” flight software to 
perform flight procedures. It can either 


assist human operators in performing 
procedures or autonomously execute 
routine cockpit procedures based on the 
operational context. Most importantly, 
the PEM autonomous framework pro- 
motes and simplifies the capture, verifi- 
cation, and validation of the flight oper- 
ations knowledge. Through a 
hierarchical decomposition of the do- 
main knowledge, the vehicle command 
and control capabilities are divided into 
manageable functional “chunks” that 
can be captured and verified separately. 
These functional units, each of which 
has the responsibility to manage part of 
the vehicle command and control, are 
modular, re-usable, and extensible. 
Also, the functional units are self-con- 
tained and have the ability to plan and 


execute the necessary steps for accom- 
plishing a task based upon the current 
mission state and available resources. 

The PEM architecture has potential 
for application outside the realm of 
spaceflight, including management of 
complex industrial processes, nuclear 
control, and control of complex vehi- 
cles such as submarines or unmanned 
air vehicles. 

This work was done by Lui Wang, Bebe Ly, 
and Alan Crocker of Johnson Space Center; 
Debra Schreckenghost oj Metrica Inc; Stephen 
Mueller and Bob Phillips of Titan-FinCom 
Corp .; and David Wadsworth and Charles 
Sorensen of Lockeed Martin Corp. For further 
information, contact the Johnson Commercial 
Technology Office at (281) 483-3809. MSC- 
23628-1 


Jitter Controller Software 

Lyndon B. Johnson Space Center, Houston, Texas 


Sinusoidal jitter is produced by simply 
modulating a clock frequency sinu- 
soidally with a given frequency and ampli- 
tude. But this can be expressed as phase 
jitter, frequency jitter, or cycle-to-cycle jit- 
ter, rms or peak, absolute units, or nor- 
malized to the base clock frequency. Jitter 
using other waveforms requires calculat- 
ing and downloading these waveforms to 
an arbitrary waveform generator, and 
helping the user manage relationships 
among phase jitter crest factor, frequency 
jitter crest factor, and cycle-to-cycle jitter 
(CCJ) crest factor. 


Software was developed for managing 
these relationships, automatically con- 
figuring the generator, and saving test 
results documentation. Tighter man- 
agement of clock jitter and jitter sensi- 
tivity is required by new codes that fur- 
ther extend the already high 
performance of space communication 
links, completely correcting symbol 
error rates higher than 10 percent, and 
therefore typically requiring demodula- 
tion and symbol synchronization hard- 
ware to operating at signal-to-noise ra- 
tios of less than one. To accomplish this, 


greater demands are also made on 
transmitter performance, and measure- 
ment techniques are needed to confirm 
performance. It was discovered early 
that sinusoidal jitter can be stepped on 
a grid such that one can connect points 
by constant phase jitter, constant fre- 
quency jitter, or constant cycle-cycle jit- 
ter. The tool automates adherence to a 
grid while also allowing adjustments off- 
grid. Also, the jitter can be set by the 
user on any dimension and the others 
are calculated. The calculations are all 
recorded, allowing the data to be rap- 
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idly plotted or re-plotted against differ- 
ent interpretations just by changing 
pointers to columns. 

A key advantage is taking data on a 
carefully controlled grid, which allowed 
a single data set to be post-analyzed 
many different ways. Another innova- 
tion was building a software tool to pro- 
vide very tight coupling between the 
generator and the recorded data prod- 


uct, and the operator’s worksheet. To- 
gether, these allowed the operator to 
sweep the jitter stimulus quickly along 
any of three dimensions and focus on 
the response of the system under test 
(response was jitter transfer ratio, or per- 
formance degradation to the symbol or 
codeword error rate). Additionally, man- 
aging multi-tone and noise waveforms 
automated a tedious manual process, 


and provided almost instantaneous deci- 
sion-making control over test flow. The 
code was written in LabVIEW, and calls 
Agilent instrument drivers to write to 
the generator hardware. 

This work was done by Chatwin Lans- 
doxune and Adam Schlesinger of Johnson 
Space Center. Further information is con- 
tained in a TSP (see page 1). MSC- 24814-1 


** jiShell Minimalist Shell for Xilinx Microprocessors 

NASA’s Jet Propulsion Laboratory, Pasadena, California 


pShell is a lightweight shell environ- 
ment for engineers and software devel- 
opers working with embedded micro- 
processors in Xilinx FPGAs. (pShell has 
also been successfully ported to run on 
ARM Cortex-Mi microprocessors in 
Actel ProASIC3 FPGAs, but without 
project-integration support.) pShell de- 
creases the time spent performing ini- 
tial tests of field-programmable gate 
array (FPGA) designs, simplifies run- 
ning customizable one-time-only experi- 
ments, and provides a familiar-feeling 
command-line interface. The program 
comes with a collection of useful func- 
tions and enables the designer to add 
an unlimited number of custom com- 
mands, which are callable from the 
command-line. The commands are pa- 
rameterizable (using the C-based com- 
mand-line parameter idiom) , so the de- 
signer can use one function to exercise 
hardware with different values. Also, 


since many hardware peripherals instan- 
tiated in FPGAs have reasonably simple 
register-mapped I/O interfaces, the en- 
gineer can edit and view hardware pa- 
rameter settings at any time without 
stopping the processor. 

pShell comes with a set of support 
scripts that interface seamlessly with Xil- 
inx’s EDK tool. Adding an instance of 
pShell to a project is as simple as mark- 
ing a check box in a library configura- 
tion dialog box and specifying a software 
project directory. The support scripts 
then examine the hardware design, 
build design-specific functions, condi- 
tionally include processor-specific func- 
tions, and complete the compilation 
process. For code-size constrained de- 
signs, most of the stock functionality can 
be excluded from the compiled library. 

When all of the configurable options 
are removed from the binary, pShell has 
an unoptimized memory footprint of 


about 4.8 kB and a size-optimized foot- 
print of about 2.3 kB. Since pShell allows 
unfettered access to all processor-accessi- 
ble memory locations, it is possible to 
perform live patching on a running sys- 
tem. This can be useful, for instance, if a 
bug is discovered in a routine but the sys- 
tem cannot be rebooted: pShell allows a 
skilled operator to directly edit the bi- 
nary executable in memory. With some 
forethought, pShell code can be located 
in a different memory location from cus- 
tom code, permitting the custom func- 
tionality to be overwritten at any time 
without stopping the controlling shell. 

This work was done by Thomas A. Werne 
of Caltech for NASA’s Jet Propulsion Labo- 
ratory. Further information is contained in 
a TSP (see page 1). 

This software is available for commercial li- 
censing. Please contact Daniel Broderick of 
the California Institute of Technology at 
danielb@caltech.edu. Refer to NPO-47495. 


® Software Displays Data on Active Regions of the Sun 

Lyndon B. Johnson Space Center, Houston, Texas 


The Solar Active Region Display Sys- 
tem is a computer program that gener- 
ates, in near real time, a graphical dis- 
play of parameters indicative of the 
spatial and temporal variations of activ- 
ity on the Sun. These parameters in- 
clude histories and distributions of 
solar flares, active region growth, coro- 
nal mass ejections, size, and magnetic 
configuration. 

By presenting solar-activity data in 
graphical form, this program acceler- 
ates, facilitates, and partly automates 
what had previously been a time-con- 
suming mental process of interpretation 
of solar-activity data presented in tabular 
and textual formats. Intended for origi- 


nal use in predicting space weather in 
order to minimize the exposure of astro- 
nauts to ionizing radiation, the program 
might also be useful on Earth for pre- 
dicting solar-wind-induced ionospheric 
effects, electric currents, and potentials 
that could affect radio-communication 
systems, navigation systems, pipelines, 
and long electric-power lines. 

Raw data for the display are obtained 
automatically from the Space Environ- 
ment Center (SEC) of the National 
Oceanic and Atmospheric Administra- 
tion (NOAA). Other data must be ob- 
tained from the NOAA SEC by verbal 
communication and entered manually. 
The Solar Active Region Display System 


automatically accounts for the latitude 
dependence of the rate of rotation of 
the Sun, by use of a mathematical 
model that is corrected with NOAA 
SEC active-region position data once 
every 24 hours. The display includes 
the date, time, and an image of the Sun 
in Ha light overlaid with latitude and 
longitude coordinate lines, dots that 
mark locations of active regions identi- 
fied by NOAA, identifying numbers as- 
signed by NOAA to such regions, and 
solar-region visual summary (SRVS) in- 
dicators associated with some of the ac- 
tive regions. 

Each SRVS indicator is a small pie 
chart containing five equal sectors, each 
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